Subject: Additions to RFC FSM

From: Bernard Brady <[email-masked]>
Date: Wed, 3 Nov 93 12:03:23 EDT

Roy,

I am sending the issues and corrections  I have on the current RFC FSM
which I believe should be incorporated into the updated version.

 Thank You

Bernie

Issue 1:

Section 4.2.2 second paragrph makes the following satement.

 	Any CANUREACH messages received in the RESOLVE_PENDING state
	will be responded to if a DLC_DL_STARTED signal is received. 
	The Data Link  Switch may also update its topology information
	based upon the origin MAC address information in each CANUREACH
	message.

In looking at the associated Event and Action routines the receipt of
CANUREACH while in this state is not listed.  This menas that receiving
a CANUREACH while in this state is ignored.

If it was to take action  and respond with multiple ICANREACH messages
means that  multiple TEST response are sent by  originating DLSw's.  It
is then the originating device which is responsible for choosing the 
route to be used which in most cases is the first response received.  
You have stated that the current 6611 implementation will respond to all
REACH_ACKs received after the first with a special HALT_DL SSP message. 
The issue is that there is no correlation between the route picked by
the originating device and the associated DLSw circuit.   By only 
acting upon the first CANUREACH received and ignoring all others this
issue goes away.

I think that this paragraph should be changed as follows

	Any CANUREACH messages received while in the RESOLVE_PENDING
state
	will be ignored.  The Data Link  Switch may update its topology
	information based upon the origin MAC address information in
        each CANUREACH message.  Only the CANUREACH messages which
	placed the circuit  into the RESOLVE_PENDING state will be 
        responded to if a DLC_DL_STARTED signal is received.

Issue 2:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>Subject: Revised NETBIOS connect flows.
>From: Bernard Brady <[email-masked]>
>Date: Wed, 1 Sep 93 10:05:11 EDT
>Message-Id: <[email-masked]>
>In-Reply-To: <[email-masked]>
>Mail-System-Version: <BBN/[email-masked]>
>
>Netbios question:
>
>Under Section 3.3 of the RFC the following paragraph stipulates what is
>contained in the exchange of DLSw NETBIOS control messages.
>
>> For the exchange of NetBIOS control messages, the entire DLC header is
>> carried as part of the message unit.  This includes the MAC header,
>> with the routing information field padded to 18 bytes, and the LLC
>> header.  The following message types are affected: NETBIOS_NQ,
>> NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when
>>  being used by NetBIOS systems.  The routing information in the DLC header
>>  is not used by the remote Data Link Switch upon receiving the above five messages.
>
>Am I correct in thinking that the entire UI frame associated with these
>messages is also contained within theses DLSw messages?
>
>Bernie Brady

Steve

the answer is yes, the entire UI frame associated with the NETBIOS_xx
and DATAFRAME is contained within the message.

I think that the RFC should clearly point out that the entire UI frame
is also included.

Issue 3:

Section 4.2.2.1 Disconnected State

Circuit Establishment Collision

For this explanation lets say two devices want to establish a connection
with one another.  In this case both determine that a route discovery is
required.  Both transmit a Test frame to locate the other. I have listed
both DLSws as originating  in this case.

I have written what I think should happen.  Can you please correct this
flow or explain  where in the RFC FSM this case is handled. 

        LAN             Origin DLSw    Origin DLSw         LAN

                   |   DISCONNECTED |  DISCONNECTED |
 Note: 1           |                |               |
                   |                |               |        <---TEST
      TEST--->     |                |               |
                   |                |               |<--DLC_RESOLVE_C
    DLC_RESOLVE_C-->                |               |
                   |                <--CANUREACH    |
                   |     CANUREACH-->               |
                   |                |               |
 Note: 2           |                |               |
                   |                |               |
                   |     REACH_ACK-->               |
                   |                |               |
                   |                <--REACH_ACK    |
                   |                |               |
 Note: 3           |                |               |
                   <--DLC_RESOLVE_R | DLC_RESOLVE_R->
           <--TEST |                |               | TEST->
                   |                |               |
                   |[CIRCUIT_ESTAB] |[CIRCUIT_ESTAB]|
                   |                |               |
                   |                |               |
                   |                |               |
                   |                |               |
                   |                |               |
                   |                |               |
                   |                |               |
                   |                |               |

Note1.	Once the TEST frame has been received both LANs present a
DLC_RESOLVE_C request to their assocaited DLSw.  On receiving a
DLC_RESOLVE_C request both DLSw's search their destination table caches
for a matching destination MAC address.  If one is found they forwards a
CANUREACH request to the associated target DLSw.  If one is not found
then they forward a CANUREACH request to each of their designated target
DLSw's.

Note 2.	On receiving the first CANUREACH request both DLSw treat them as
 an ICANREACH response from the target DLSw.  All other received
CANREACH messages are ignored. 

If this is true then this requires a change to the FSM given in the RFC. 
In this case if a CANUREACH is recieved for a destination/source MAC SAP
pair which the originating DLSw is waiting for an  ICANREACH then the
CANUREACH is treated as an ICANREACH.

Note 3.	In the process of sending REACH_ACK the DLSw will also send a
DLC_RESOLVE_R response to the data link interface.   This informs the
data link interface to respond to the original TEST or XID request which
started the route discovery process.  Receipt of the REACH_ACK is
iognore by both DLSws since there in the CIRCUIT_ESTAB state